COMMENT ⊗   VALID 00007 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	*** DRAFT ***	*** DO NOT BELIEVE ***	*** DO NOT DUPLICATE ***  *** DRAFT ***
C00004 00003				PREFACE
C00007 00004				INTRODUCTION
C00011 00005				MOTIVATIONS
C00013 00006				MAIL COMMAND CODES
C00014 00007				MAIL PROCEDURE
C00015 ENDMK
C⊗;
*** DRAFT ***	*** DO NOT BELIEVE ***	*** DO NOT DUPLICATE ***  *** DRAFT ***
DIALnet memo #3















		     DIALnet Protocols

		(or, the Protocols of DIAL)

		      MAIL Protocols

			  9/16/77














     These protocols are being  developed  as  part  of  the
DIALnet   project  at  the  Stanford  University  Artificial
Intelligence Laboratory supported by NSF grant MCS  77-02080
with  John McCarthy as Principal Investigator.   The project
is  described in a  paper  available online  at ARPAnet host
SU-AI (octal 13, decimal 11) as DIALNE.MEM[DLN,MRC]

*** DRAFT ***	*** DO NOT BELIEVE ***	*** DO NOT DUPLICATE ***  *** DRAFT ***
			PREFACE

This document specifies a protocol for use in communication between
Host computers on the DIALnet network.  In particular, it provides for
connection of independent processes in different hosts, control of
the flow of data of established connections, and other related
functions.

Although self-contained, this document specifies only one of the
DIALnet protocols.  In particular, this protocol specifies how
"mail" is to be transmitted between hosts on DIALnet.

This "mail" protocol is one of the "third level", or tertiary protocols,
used on DIALnet.  The Host-Network protocol, or primary protocol, is
currently the same as the RS232C communication protocol.  The Host-Host
protocol, or secondary protocol, is described elsewhere, as are the
other tertiary protocols.

Questions concerning DIALnet protocols should be addressed to:

Mark Crispin
Stanford Artificial Intelligence Laboratory
Stanford, California  94305
(415) 491-1407
MRC @ SU-AI

Copies of all DIALnet-related correspondence should be sent to John
McCarthy, DIALnet principal investigator, and Les Earnest at the above
US mail address or to JMC@SU-AI and LES@SU-AI.

It is the intent of the author that these protocols are both simple
in their implementation and powerful in their operation.  Certainly
a major design consideration was to design protocols that ordinary
mortals could implement on their systems.

The intended audience of DIALnet ranges from fairly small to quite
large systems, however, DIALnet has been designed to be nice for
medium sized time-sharing systems, such as PDP-10's and DECsystem-20's.
			INTRODUCTION

DIALnet provides a capability for geographically separated computers,
called Hosts, to communicate with each other.  The Host computers
typically differ from one another in typpe, speed, word length,
operating system, etc.  Each computer utilizes the network via the
ordinary phone lines and special modems using the primary protcol.

This protocol, however, is insufficient to specify meaningful
communication between processes running in two dissimilar hosts.
Therefore, the secondary protocols were implemented, which allowed
for two processes, one at each end, called the NCP (Network Control
Program), to communicate with each other over DIALnet, serving as
an interface to handle traffic between a process on its own system
and the network.

This alone is sufficient for communication between cooperating
processes on DIALnet, despite dissimilarities in the two hosts.
However, this alone is not enough; for several services, as discussed
in the Host-Host protocols, are of general use to the network
community as a whole and without a standard, a series of incompatable
private protocols would evolve, and the network will split into many
mini-networks.

It is not the intention to prevent private protocols from arising;
indeed, many groups of hosts with common interests will doubtless
want to establish private protocols between themselves to handle
their special needs.  The intention rather is to provide the DIALnet
community with a set of standards of certain services that are of
utility to the entire network as a whole, and which most hosts will
want to implement so that they may use this service in communication
with all the other hosts on DIALnet.

This document describes a protocol for sending "mail" over the
network.  At this stage of design, mail services are intended to
be for person-to-person communication; however, room will be left
for future extensions so that a general entity-to-entity mail
service is available.
			MOTIVATIONS

The design of the mail system has been influenced by the following
motivations:

	.  To avoid repeating the mistakes of ARPAnet mail.

	.  To have a system that is simple to implement and use,
	   such that ordinary mortals can comprehend.

	.  To establish strict mail formats with no ambiguity of
	   format, to prevent the proliferation of mail header
	   formats which has occured in the ARPAnet.

	.  To keep the mail headers which are actually inserted
	   into the message minimal, containing only a date, return
	   address, and subject.

	.  To provide extra information, if needed, as part of the
	   mail protocol, and not in the mail header.

	.  To allow the mail sender complete freedom in what is
	   included in the actual body of the mail message.

The following are currently non-goals.  It is felt that there is no
justification at the present time to consider these matters.

	.  Compatability with ARPAnet mail.

	.  Message security.

	.  Explicit forwarding.

	.  Detection and deletion of duplicate copies of a message
	   or of mail loops.
			MAIL COMMAND CODES

The two mail processes communicate with each other using mail
command codes.  These codes are three-digit octal numbers which
are used to pass information to the other side.  After the code
there is the code argument, which contains additional information
for that particular function.  In some cases, no argument is
needed; in these cases the argument is labeled as a "comment".
An argument terminates with a carriage return.

The codes are set up such that the high order digit indicates the
type of message.
			MAIL PROCEDURE

The mail sender connects to the mail server process (process ID
MAIL), in the manner described in the Host-Host protocols.

The mail receiver (or server) should then send the user a greeting
message to indicate it is alive and that it is ready for mailing
commands.